Many web-sites require that a user provides evidence of their identity before they can access the web-site. This process is generally referred to as “user authentication”, and typically requires that a user enter a username and a key that (supposedly) is known only to the user and to the administrator of the web-site. The key may be a static key that is valid indefinitely or it may be a one-time key that can be used only once. A key may be, for example a password or passphrase, or a personal identification number (PIN) and, in general terms, may be any string of letters, numerals and/or other characters such as spaces and punctuation marks.
User authentication when logging in to web-pages and applications on the web is cumbersome, particularly if a user wishes to log-in to a number of different web-pages and/or applications. The user has to check the URL or other non-comprehensive security indicators of the web-page being accessed to make sure that he sends his username and password to the intended server/application. The transmission to the server is usually protected by TLS (transport layer security).
If one time passwords are used, they may exhibit the nice feature that the user has to enter a PIN to generate a password. This is good as the authentication cannot take place without explicit user interaction. There are however several known problems with this solution.
The user may have to remember many different usernames and passwords to ensure security separation between services. This can be difficult. It is known for a user to use the same password for more than one service to reduce the number of keys that they have to remember, but this may lead to a loss of security.
Often users can be fooled to submit their username and password to a server emulating the service or when connecting to a “phishing” site. This is in particular a problem, since manual verification of URLs or security indicators such as certificate owners is very difficult for most users, and it is difficult even for a knowledgeable user if, e.g., internationalized domain names are used.
Desktop browsers and mobile browsers implement today a so-called “password management” function that detects sites requesting authentication and store the user-provided username and password with the corresponding URL, to avoid the user having to remember all their passwords and usernames. However, the stored information can only be used for the browser itself, and it can't be used across other external browsers. In addition, the password manager keeps the passwords stored on the device, and if any malicious code should invade the device it may be able to get access to the password database and thereby lead to loss of security.
The GBA process is a key generation/distribution function that is standardised in 3GPP and 3GPP2. The main application is to provide keys that can be used for user authentication and set-up of protected connections between a mobile telephone and a service in the operator network.
The triggering of the key generation is controlled by the mobile telephone, and the server can only obtain a key after being contacted by the mobile telephone.
For completeness, a brief description of GBA will be included herein. This is taken from the 3GPP specification 3GPP TS 33.220.
FIG. 4 shows a simple network model of the entities involved in the bootstrapping approach, and the reference points used between them.
A generic bootstrapping server function (BSF) 7 and the user equipment (UE) 8 mutually authenticate using the AKA protocol, and agree on session keys that are afterwards applied between the UE 8 and a network application function (NAF) 9. The BSF 7 shall restrict the applicability of the key material to a specific NAF by using a well-defined key derivation procedure, which includes among other entities the “name” of the NAF 9. The key derivation procedure may be used with multiple NAFs during the lifetime of the key material. The lifetime of the key material is set according to the local policy of the BSF 7.
The basis of the key generation is the UMTS AKA mechanism which, from a RAND with the help of user unique functions, derives two keys, Ck and Ik. The concatenation of these keys into a 256 bit entity is denominated Ks.
The BSF 7 retrieves an authentication vector from the HSS 10 and generates the key material Ks by concatenating Ck and Ik. A key identifier B-TID is generated in the format of a NAI by taking the base64 encoded RAND value and the BSF server name, i.e. as base64encode(RAND)@BSF_servers_domain_name.
The UE 8 authenticates itself towards the BSF 7b according to the http digest AKA specification (RFC 3310). In this protocol the BSF 7 sends a RAND and the corresponding AUTN to the UE 8. The UE 8 responds with a digest based on the RES from the AKA procedure. At the same time the Ck and Ik keys are generated.
The BSF 7 shall be able to acquire the GBA user security settings (GUSS) from the HSS 10.
After the bootstrapping has been completed, the UE 8 and a NAF 9 can run an application specific protocol where the authentication of messages will be based on those session keys generated during the mutual authentication between the UE 8 and the BSF 7.
General assumptions for the functionality of a NAF are:                there is no previous security association between the UE 8 and the NAF 9;        the NAF shall be able to locate and communicate securely with the subscriber's BSF;        the NAF shall be able to acquire a shared key material established between UE and the BSF during the run of the application-specific protocol;        the NAF shall be able to acquire zero or more application-specific USSs from the HSS via the BSF;        the NAF shall be able to set the local validity condition of the shared key material according to the local policy;        the NAF shall be able to check lifetime and local validity condition of the shared key material.        